Telegram Group & Telegram Channel
Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:


class Disease {
var confirmed: Confirmed
}

enum class Confirmed {
YES, NO, NOT_SPECIFIED
}


Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
// какие-то проверки
this.confirmed = c
}


У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
// какие-то проверки
this.confirmed = Confirmed.YES
}

fun decline(){
// какие-то проверки
this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES


Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

Но это ладно, когда мы знаем какой параметр передать, — это самый легкий случай. Иногда нужно знать последовательность вызовов или даже тайминг. Вообще, степень такой связности обозвали даже специальным словом Connascence.

Поэтому, когда вы пишете модуль, подумайте над следующим:
- Что вы можете скрыть и не показывать?
- Какие изменения внутри вашего модуля могут затронуть клиента?
Вы удивитесь, насколько проще клиенту будет работать с вашим модулем.



tg-me.com/stringconcat/226
Create:
Last Update:

Теперь немного подушним. За свою карьеру я-таки заметил одну вещь, от которой у меня пригорает. Многие разрабы не умеют в инкапсуляцию, от чего кишки классов и модулей часто вываливаются наружу.

Рассмотрим на примере. Представим что у нас есть вот такой класс:


class Disease {
var confirmed: Confirmed
}

enum class Confirmed {
YES, NO, NOT_SPECIFIED
}


Мы можем подтвердить диагноз или отклонить его. Как бы вы реализовали?
Нам обычно попадается такое:

fun setConfirmed(confirmed: Confirmed){
// какие-то проверки
this.confirmed = c
}


У такой реализации есть недостатки. Клиент теперь чуть больше знает о реализации вашего модуля: оказывается, есть какой-то енумчик, который нужно передать внутрь. Ещё это сложно рефакторить: как найти все места, в которых передается Confirmed.YES, учитывая что значение не везде передается константо? А если мы захотим поменять YES на CONFIRMED, сколько классов придется поправить? А можно ли передавать в метод NOT_SPECIFIED или же мы получим ошибку?

Пример примитивный, но объём кучи навоза уже можно прикинуть. И многие разработчики не думают, как грамотнее инкапсулироваться, вываливают всё наружу, а потом жалуются, что у них всё слиплось.

Правильнее сделать примерно так:

fun confirm(){
// какие-то проверки
this.confirmed = Confirmed.YES
}

fun decline(){
// какие-то проверки
this.confirmed = Confirmed.NO
}

fun confirmed() = this.confirmed == Confirmed.YES


Методов больше, но зато внешний клиент знает меньше про устройство модуля, мы легко можем найти все вызовы без угадайки. К тому же светить Enum может оказаться совсем необязательным, ибо с точки зрения предметки нас интересует только факт подтвержденности диагноза, а что там внутри за статусы — вообще пофигу.

Но это ладно, когда мы знаем какой параметр передать, — это самый легкий случай. Иногда нужно знать последовательность вызовов или даже тайминг. Вообще, степень такой связности обозвали даже специальным словом Connascence.

Поэтому, когда вы пишете модуль, подумайте над следующим:
- Что вы можете скрыть и не показывать?
- Какие изменения внутри вашего модуля могут затронуть клиента?
Вы удивитесь, насколько проще клиенту будет работать с вашим модулем.

BY StringConcat - разработка без боли и сожалений


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/stringconcat/226

View MORE
Open in Telegram


StringConcat разработка без боли и сожалений Telegram | DID YOU KNOW?

Date: |

However, analysts are positive on the stock now. “We have seen a huge downside movement in the stock due to the central electricity regulatory commission’s (CERC) order that seems to be negative from 2014-15 onwards but we cannot take a linear negative view on the stock and further downside movement on the stock is unlikely. Currently stock is underpriced. Investors can bet on it for a longer horizon," said Vivek Gupta, director research at CapitalVia Global Research.

Telegram hopes to raise $1bn with a convertible bond private placement

The super secure UAE-based Telegram messenger service, developed by Russian-born software icon Pavel Durov, is looking to raise $1bn through a bond placement to a limited number of investors from Russia, Europe, Asia and the Middle East, the Kommersant daily reported citing unnamed sources on February 18, 2021.The issue reportedly comprises exchange bonds that could be converted into equity in the messaging service that is currently 100% owned by Durov and his brother Nikolai.Kommersant reports that the price of the conversion would be at a 10% discount to a potential IPO should it happen within five years.The minimum bond placement is said to be set at $50mn, but could be lowered to $10mn. Five-year bonds could carry an annual coupon of 7-8%.

StringConcat разработка без боли и сожалений from it


Telegram StringConcat - разработка без боли и сожалений
FROM USA